The invention relates generally to the field of multi-processor computer systems, and more specifically, to the emulation of input or output data and the communication of and/or commands to or from a processor that is executing an I/O instruction directed to a specified I/O device in a multi-processor computer system environment.
This invention also relates generally to the field of SMI services and multi-Processor computer systems and specifically to the field of servicing Software SMI""s.
The modern computer architecture typically includes a set of hardware called Legacy Hardware. This Legacy Hardware is hardware that all applications, operating systems and BIOS (Basic Input/Output System firmware used to boot and to test the architecture as well as to provide run-time services) expect to be present in the computer system and expect to behave in the computer system in a prescribed way. To communicate with diverse hardware in a given architecture, a series of Input and Output instructions along with specified addresses and data values have been standardized. When removing or adding new hardware in the computer system, in order to allow all existing applications and operating systems software to make use of the new hardware without modification, the Input/Output instructions between the new hardware and the old system hardware typically require emulation, which is accomplished by dispatching the Input/Output instructions to a software emulation subroutine. This is also referred to as trapping. A specific example of hardware requiring an emulation operation is the Universal Serial Bus (USB) Legacy support system. The USB hardware in this support system adds to the overall computer system the following: A USB host controller, a root hub, a connector, interrupt generating mechanisms, and USB devices including a USB keyboard. For all existing applications and operating systems to take advantage of the USB keyboard, this keyboard at the Input/Output instruction level must be made to look like the original keyboard used with the Legacy Hardware, for example, a PS/2 keyboard. To emulate the PS/2 keyboard, a System Management Interrupt (SMI) is generated by trapping on the PS/2 keyboard controller Input/Output instructions. Within the SMI service routine, specific routines then translate the command/data from the Legacy Hardware format to USB keyboard command/data.
A fundamental problem results from the use of such interrupts in a multi-processor environment. This problem when interrupts are utilized, is to determine which processor in the multi-processor environment caused the instruction trap. The emulation of an IN instruction, for example, can cause significant problems if that command or data is not loaded into the proper register in the processor that initiated and executed the input instruction. Likewise, the emulation of an OUT instruction, although it will not cause corruption of registers in a processor, will cause incorrect data to be provided to the output device if the data is not received from the processor that executed the OUT instruction.
In a typical multi-processor architecture, if no changes are made to the I/O instruction emulation, the Boot Strapped Processor (BSP) will have one of its registers changed when one of the Application Processors in the multi-processor architecture performs an input instruction requiring emulation. This causes two problems: (1) the input instructions data is never received by the application processor that performed the input instruction; and (2) one of the Boot Strapped Processor""s registers is inadvertently changed, which could have a disastrous effect.
Likewise, with no changes to the output instruction emulation, the emulation code would only get the output data from the Boot Strapped Processor, even if one of the Application Processors performed the output instruction. This causes two problems: (1) the Application Processor output instruction data will never be received by the output instruction emulation code; (2) one of the Boot Strapped Processor""s registers will be used as the output instruction data which could put the emulated device into an undesirable state. The present invention is designed to solve both of these problems.
In general, modern CPU hardware such as the Intel Pentium includes a provision for a System Management Interrupt (SMI) signal. The interrupt is connected to an output pin from the computer system""s chipset logic. When certain system hardware events occur, external to the CPU(s) of a system, such as chipset logic""s programmable timers timing out, error conditions such as parity errors, low battery indications from external hardware, and particular BUS I/O cycle execution, the chipset logic will generate the software management interrupt (SMI) signal. This interrupt transfers CPU execution to a BIOS SMI interrupt handler for further processing, which is usually implemented by a software module.
In addition to pure hardware events, the SMI feature can also be invoked deliberately by software through the use of a software SMI procedure. In general, a software SMI procedure executes one or more I/O instructions that the chipset logic has been programmed to monitor. Upon detection that the I/O cycle has occurred, the chipset logic will generate the SMI signal to the SMI pin(s) of the CPU(s). The chipset logic in this situation is simply monitoring I/O Bus cycles (treating them as hardware events), and so has no knowledge which CPU actually generated the instruction.
In the case of SMI""s generated by external hardware events, the state of the registers of the various CPU(s) of the system are largely irrelevant to the interrupt handling. The hardware event is CPU independent and the BIOS""s SMI handler is simply given control to handle the hardware event and then, following the handling, it allows the system to resume it""s normal processing. The CPU(s) themselves generally input no information and require no information to be passed back to them.
However, in the case of an SMI generated deliberately by software (S/W SMI), it is generally necessary to pass information into the SMI handler and to also get results back. For example, in the case of a software SMI used to enable a power management function, the results would be control information communicated to one or more registers in the particular CPU to power-up or power lower given pieces of equipment connected to that CPU. As another example, a software SMI may be generated in order to enable a MODEM, and the results to be communicated back to a register in the particular CPU is whether the MODEM was or was not enabled. As a yet further example, a software SMI may be generated in order to check a password, and the result to be communicated back by changing a register in the particular CPU is whether the entered password matches a stored set of accepted passwords.
In the case of a single CPU, results are passed by reading the standard CPU registers by the SMI handler and output is retrieved by changing these registers in the CPU upon resume. However, in the case of multiple CPUs a new problem arises because the individual CPU which generated the Software SMI has never been readily determinable and thus the CPU registers to read as input and to write data are not known.
With no changes to the software SMI functionality, the Boot Strapped Processor (BCP) will have its register used for any input and output changes when one of the Application Processor(s) (AP""s) performs a software SMI. This causes two problems: 1) The Input Instruction""s data is never received by the AP. 2) The BCP""s registers were inadvertently changed which could have a disastrous effect. Support for multiple CPUs has never been performed.
Briefly, the present invention comprises a multi-processor system, including at least a first and a second processors, each capable of executing an I/O instruction to transfer data or a command between the processor and an I/O device; I/O and trap hardware for performing an interrupt on a plurality of the processors upon receipt of a selected I/O instruction from one of the processors and to transfer data or a command between the I/O device and the one of the processors; a first device for determining which of the processors are executing I/O instructions; a second device operating, when only one of the processors is executing an I/O instruction, to set a LastProcessor indicator designating the one processor as the processor executing an I/O instruction; and a third device for transferring data or a command between the processor indicated in the LastProcessor indicator and the I/O device in response to the selected I/O instruction.
In a further aspect of the present invention, the I/O and trap hardware comprises an emulation block for translating the data or command from one of the input device or processor to a different format compatible with the other of the input device or processor.
In a yet further aspect of the present invention, the first device for determining which of the processors is executing an I/O instruction comprises first circuitry for designating for each of a plurality of the processors, whether an instruction address count difference between an instruction address for an I/O instruction last performed by that processor and a current instruction address for that processor is less than or equal to a predetermined number, and using this designation in determining which of the processors are executing an I/O instruction.
In a yet further aspect of the present invention, the first circuitry includes logic to determine when the instruction address count difference for a particular processor is equal to one, and to delete the designation of that particular processor as a processor executing an I/O instruction unless the last I/O instruction for the particular processor designates directly or indirectly a port for the specific I/O device.
In a yet further aspect of the present invention, the predetermined number is 2.
In a yet further aspect of the present invention, each of the first and second processors includes a first logic to set a first indicator when it is executing an I/O instruction; and wherein the first device comprises a second logic to determine which of the processors have their first indicators set.
In yet a further aspect of the present invention, a method is provided for controlling I/O in a multi-processor environment, comprising the steps of: determining if an I/O instruction requiring an interrupt is being executed by one of the processors in the multi-processor environment to transfer data or a command between the processor and an I/O device; performing an interrupt if such an I/O instruction is detected; determining which of the processors in the multi-processor environment is executing an I/O instruction; if only one of the processors is executing an I/O instruction, setting a LastProcessor indicator designating that one processor as the processor executing the I/O instruction; and transferring data or a command between the processor designated in the LastProcessor indicator and the I/O device in response to the I/O instruction.
In yet a further aspect of the invention, a computer program product is provided comprising: a computer usable medium having computer readable program code means embodied therein for providing I/O functions between an appropriate processor in a multi-processor environment and an I/O device during an I/O trap, the computer readable program code means in the computer program product comprising first computer readable program code means for causing hardware to determine which processors in the multi-processor environment are executing an I/O instruction; second computer readable program code means for causing hardware to determine if only one of the processors in the multi-processor environment is executing an I/O instruction, an in that case, setting a LastProcessor indicator designating the one processor as the processor executing an I/O instruction; and third computer readable program code means for causing hardware to transfer data or a command between the processor designated by the LastProcessor indicator and the I/O device.
In a yet further aspect of the present invention, a multi-processor system is provided comprising at least a first and a second processor, each capable of executing an I/O instruction to transfer data or a command between the processor and an I/O device; an I/O and trap hardware for performing an interrupt on a plurality of the processors upon receipt of a selected I/O instruction from one of the processors and to transfer data or a command between the I/O device and the one of the processors; a first device for providing a designation, for each of a plurality of the processors whether an instruction address count difference between an instruction address for an I/O instruction last performed by that processor and the current instruction address for that processor are less than or equal to a predetermined number, and using this information in determining which of the processors to connect the I/O device to transfer data or a command between the I/O device and that processor in response to the I/O instruction, and making that connection.
In a yet further aspect of the present invention, a method for controlling I/O in a multi-processor environment is provided, comprising the steps of: determining if an I/O instruction requiring an interrupt is being executed by one of the processors in the multi-processor environment to transfer data or a command between the processor and an I/O device; performing an interrupt if such an I/O instruction is detected; providing a designation of which of the processors in the multi-processor environment has an instruction address count difference between an instruction address for an I/O instruction last performed by that processor and a current instruction address for that processor which is less than or equal to a predetermined number; and using that information in determining which processor to connect to the I/O device to transfer the data or command between the I/O device and the processor in response to the selected I/O instruction and making that connection.
In a further aspect of the present invention, a method for servicing a software system management interrupt (SMI) initiated by an I/O instruction in a multi-processor environment is provided, comprising the steps of: detecting the occurrence of a software SMI; determining which processor in the multi-processor environment has save state information indicating that that processor initiated the software SMI; and transferring information between an SMI handler and the processor determined to have initiated the software SMI.
In a further aspect of the present invention, the processor determining step comprises the step of determining if a processor in the multi-processor environment has an EIPxe2x80x2 value in an interrupt save area equal to an offset location where an instruction which immediately follows an I/O call instruction that initiates software SMI""s in a BIOS software SMI call routine exists.
In a yet further aspect of the present invention, the processor determining step comprises the step of determining if the EIP value in a processor I/O save state area equals an offset location at which an I/O call instruction that initiates software SMI""s in a BIOS software SMI call routine exists.
In a further aspect of the present invention, a multi-processor system is provided, comprising: at least a first and a second processors, each capable of initiating a software-generated system management interrupt (SMI) by generating a particular I/O call instruction in a BIOS software SMI call routine; an SMI handler for processing system management interrupts; first logic for detecting the occurrence of a software SMI; second logic for determining, after the first logic has detected the occurrence of a software SMI, which processor in the multi-processor environment has save state information which indicates that processor as having initiated the software SMI; and third logic for transferring information between the SMI handler and the processor determined to have initiated the software SMI.
In a further aspect of the present invention, a computer program product is provided, comprising a computer usable medium having computer readable program code means embodied therein for determining which processor in a multi-processor environment initiated a software system management interrupt (SMI) and providing communication between an SMI handler and that processor, the computer readable program code means in the computer program product comprising: first computer readable program code means for detecting the occurrence of a software SMI; second computer readable program code means for designating, after the first computer readable program code means has detected the occurrence of a software SMI, which processor in the multi-processor environment has save state information which indicates that processor as having initiated the software SMI; and third computer readable program code means for transferring information between the SMI handler and the processor determined to have initiated the software SMI.
Is yet a further aspect of the present invention, a computer program product is provided, comprising: a computer usable medium having computer readable program code means embodied therein for determining which processor in a multi-processor environment initiated a software system management interrupt (SMI) and providing communication between an SMI handler and that processor, the computer readable program code means in the computer program product comprising: first computer readable program code means for detecting the occurrence of a software SMI; second computer readable program code means for designating, after the first computer readable program code means has detected the occurrence of a software SMI, a processor in the multi-processor environment as having initiated the software SMI if both of the following tests, in any order, are true:
1) the processor in the multi-processor environment has an EIPxe2x80x2 value in an interrupt save state area equal to an offset location where an instruction which immediately follows an I/O call instruction that initiates software SMI""s in a BIOS software SMI call routine exists, and
2) the EIP value in an I/O save state area for the processor equals an offset location at which an I/O call instruction that initiates software SMI""s in the BIOS software SMI call routine exists; and
transferring information between the SMI handler and the designated processor.